Data security system and method

ABSTRACT

A system and method are disclosed for secure storage of customer&#39;s public and private data in a personal data store. Companies communicate with a secure data storage server using a public encryption key linked to a registered IP Address, customers communicate with a private encryption key, and encrypted data can be stored using a variety of encryption keys. The personal data store can be used for preparing customer product views, linking personal data to avoid repeated customer data entries, customer identification and loyalty card linking. Encrypted stored data ensures no other person can read it.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is continuation of U.S. Ser. No. 15/503,397 filed Feb.12, 2017, now U.S. Pat. No. 10,762,543, which is a § 371 ofInternational Application PCT/GB2015/000234 filed on Aug. 11, 2015,which in turn claims the benefit of Great Britain applicationGB1414302.8 filed on Aug. 12, 2014, which are hereby incorporated byreference in their entirety.

FIELD

The present invention relates to secure data storage and access in thearea of Internet and other network access. The invention particularlyrelates to sensitive data which would, for example, be useful to thosewho exploit virus infections and other forms of malware to steal orotherwise exploit individual data. The invention further relates tomaking personal data available for legitimate use while all the timeensuring data security.

BACKGROUND

United States Patent Application US2014164790 (A1) discloses methods andsystems for administrative management of a secure data storage networkare disclosed. One system includes a secure storage appliance configuredto host a plurality of volumes, each volume associated with a pluralityof shares stored on a corresponding plurality of physical storagedevices and having a plurality of volume management settings, whereineach volume is accessible by a group of one or more users, each userassigned an administrative access level, the volume management settingsare editable by a first user from the group of one or more usersassociated with the volume and assigned an administrative access levelsufficient to edit the volume management settings, and the volumemanagement settings are inaccessible by a second user from outside thegroup of one or more users associated with the volume and assigned anadministrative access level at least equal to that of the first user.The present invention seeks to provide improvement there over byproviding greatly simplified data protection arrangements while allowingfree and a varied access without risk of information divulgence.

United States Patent Application US2014164777 (A1) discloses a remotedevice secure data file storage system and method of securely storingdata files at a remote device, includes a host system having a databaseand a plurality of remote devices, each connected with the host systemby a communication network. Each remote device and the host system isprogrammed with a time-based cryptography system that generates anencryption key (RVK) and initialization vector (IV) for encrypting anddecrypting data on the remote device. The time-based cryptography systemgenerates the encryption key (RVK) as a function of a parameter (PDPT)that is a function of a personal date (PD) and personal time (PT) of theuser. The personal date and personal time of the user being a functionof personal data entered by the user on the remote device. The personaldate (PD) is a function of the date of birth (DOB) of the user and thepersonal time (PT) is a function of the time of birth (TOB) of the user.The present invention seeks to provide improvement there over bysimplifying the selection of keys whilst at the same time allowing freeand varied access without risking data disclosure.

A first problem exists in that a user's data through their commerciallife is not available from any single website to be stored or accessed.Much relevant data exists for each of us. To give but a small sample,isolated files exist for each of us with regards to banks, insurance,telecommunications suppliers, utilities and national/local taxationdetails. To collect such data together today would require multiplelogins to each company/product and potentially insecure passing ofpersonal data between multiple suppliers systems and the website. Thepresent invention seeks to provide bidirectional company-to-customersecure communications to a central personal data store while minimisingconfidential information travelling by interceptable data such aspacket.

It is to be noted that the UK government is implementing a service basedon the use of individual personal data stores for just such a purpose,using a product from the community interest company “Mydex”.

A second problem exists when a user may have several products from thesame company, but, as the company or companies systems are arranged on a“product-silo” basis, it is often difficult to create a “single customerview” of all of the products a customer has. This often entailscomplex/error-prone matching of customer details across the systems. Thepresent invention seeks to improve upon the situation by creating a“single customer view” by matching data in the personal Data store andmultiple, disparate company systems, and associated challenge/responsewith the customer.

A third problem occurs in that a user often complains that talking tothe right person in the company is very error-prone and that the userconstantly have to provide the same security or personal data at eachstep along the chain until the right person is found. The presentinvention seeks to provide improvement there over by ensuring routing ofsupport calls based on an individuals attributes (for example, high-endworth, or having a relationship manager) and with authentication fromthe personal Data store.

A fourth problem occurs when a user comes to purchase financial or otherservice-based products online, in that they often have to providesignificant amounts of personal and identity/historic or paymentdetails. Such information must be repeated for each supplier, althoughthe data required from various only very slightly across each supplier.The present invention seeks to significantly reduce provision ofpersonal data.

A fifth problem can occur when users may wish to aggregate all of theirexisting policies or products with one or more suppliers into a website.However, this often entails supplying existing logon or identityinformation for each product which is manually entered by the user. Thisis both insecure and time-consuming and requires the user to have set upfor access to each product previously. The present invention seeks toobviate multiple logons and to reduce the associated data-transfer risk.

A sixth problem can occur when a user is in a physical retail outlet andonce to purchase a product, they are then required to providesignificant personal information verbally which is then entered by theagent. This is both time-consuming and error-prone, and is duplicatedacross lots of suppliers a customer may make purchases from. The presentinvention seeks to alleviate the data supply burden.

A seventh problem occurs when often users are members of a number ofloyalty programs for credit cards (e.g. nectar), petrol, stores,airlines and a never ending list. However, it is often a requirement tocarry physical evidence of membership of a loyalty program, as well ashaving to submit proof of purchase. Subsequent redemption of loyaltypoints is often seen difficultly after visiting a member store and hencethe ability to redeem points at point of sale is wasted. The presentinvention seeks to allow loyalty transactions to be made employing apersonal data store, allowing real-time loyalty offers via the point ofsale. Also this would allow gathering evidence of purchase.

SUMMARY

According to a first aspect, the present invention consists in a system,including a network allowing bidirectional communication there through,the system comprising:

a secure data storage server including a personal data store for storinguser personal data and user private data relating to the user, thesecure status storage server being able bidirectionally to communicatewith at least one client device and at least one service providerclient;

where the at least one service provider client communicates with thesecure data storage server with data encrypted using a first encryptionkey;

where the at least one client device communicates with the secure datastorage server with data encrypted using a second encryption key;

where the at least one service provider client stores private data inthe personal data store encrypted using a third encryption key;

and where the at least one client device stores personal data in thepersonal data store encrypted using a fourth encryption key.

According to a second aspect, the present invention consists in amethod, including employing a network allowing bidirectionalcommunication there through, the method comprising the steps:

a step of providing a secure data storage server including a personaldata store for storing user public personal data and user private datarelating to the user, the secure status storage server being enababledbidirectionally to communicate with at least one client device and atleast one service provider client;

a step of the at least one service provider client communicating withthe secure data storage server with data encrypted using a firstencryption key;

a step of the at least one client device communicating with the securedata storage server with data encrypted using a second encryption key;

a step of the at least one service provider client storing private datain the personal data store encrypted using a third encryption key;

and a step of the at least one client device stores personal data in thepersonal data store encrypted using a fourth encryption key.

The invention further provides that the first encryption key can be adedicated company communications encryption key.

The invention further provides that the second encryption key can be adedicated customer encryption key.

The invention further provides that the third encryption key can be thefirst encryption key.

The invention further provides that the fourth encryption key can be thesecond encryption key.

The invention yet further provides that the second encryption key can bea company private encryption key.

The invention yet further provides that the fourth encryption key can bea customer private data encryption key.

The invention further provides that the at least one service providerclient can access the personal data store(s) only from previouslyregistered IP addresses.

The invention further provides that the at least one service providerclient alone can have rights to access and change data that at least oneservice provider client provides.

The invention further provides that the secure data storage server cancomprise a Crypt app server for cooperating with a client device, thecrypt app server communicating, when used, with the secured data storageserver to provide services.

The invention further provides that the secure data storage server canbe operable to compare company data with private data to assemble asingle customer view wherein all company private data is assembled andcan be displayed for an individual customer, and that the comparedprivate data can be from a single service provider client. Multipleviews for multiple companies data for the same customer can be created

The invention further provides that a customer can contact the Crypt appserver to link a service provider client supportable product to thatcustomer, that the service provider client can then use the customer'sindividual public data to verify the customer's identity and then tostore contact information in the private data store to enable thecustomer to contact the service provider client company with contacthistory.

The invention provides that the customer can place a call to the Cryptapp server and the Crypt app server can cause the contact information tobe retrieved and the call automatically to be correctly relayed to theservice provider client company at the same time causing the contacthistory to be made visible to the respondent at the service providerclient company.

The invention can further comprise a context data store that can beoperable to store results from the crypt app server.

The invention further provides that when the customer uses the clientdevice to contact the Crypt app server to seek purchase of a servicefrom a service provider client company, the service provider clientcompany can access the customers public data to fill a validationtemplate before accepting or rejecting the customer for sale or offer ofa product.

The invention further provides that the service provider client company,if the particular requirements for customer validation are not met, canrequest further data from the customer, satisfactory provision whereofallows progress towards sale or offer of the product.

The invention further provides that a point of sale terminal can becoupled to the secure data storage server; that a client device cantransfer data to the point of sale terminal identifying a customer; andthat the point of sale terminal can transfer the customer identifyingdata to the secure data storage server for the customer's identity to beverified.

The invention further provides that the client device can transfer datato the point of sale terminal by at least one of: near fieldtransmission; and optical imaging of an image displayed on a display onthe client device.

The invention further provides that the optical image can be aone-dimensional or two dimensional barcode giving customeridentification information.

The invention further provides that a customer can access the Crypt appserver to link products and sales to loyalty schemes.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention is described, by way of examples, to be read inconjunction with the appended drawings, in which:

FIG. 1 is a schematic diagram illustrating one possible environmentwhere in the present invention can be practised;

FIG. 2 is a schematic diagram illustrating in greater detail thearrangement of FIG. 1 when executing a task;

FIG. 3 provides an exemplary possible flow chart that can be executedusing the apparatus of FIG. 2;

FIG. 4 is a schematic diagram showing how the personal data store ofFIGS. 1 and 2 stores two types of data;

FIG. 5, is an exemplary flow chart illustrating one way in which thesecure data storage server can create a “single customer view” fromdiverse data;

FIG. 6A is an exemplary flowchart illustrating one way in which theinvention can be employed to create links between a product and a user;

FIG. 6B, an exemplary flow chart illustrating one way in which the appserver coupled with a context data store can interact with a user makinga call seeking product assistance from a company; and

FIG. 7 is an exemplary flow chart illustrating one possible way in whichthe present invention assists to resolve the fifth problem.

DETAILED DESCRIPTION

The invention is now described in detail by way of examples.

Attention is drawn to FIG. 1, a schematic diagram showing an environmentin which the present invention can be practised.

A first example is here provided where in a company provides the inputto the service provider client 14 to indicate to a customer, being theuser, but not necessarily at that time, of a client device 12.

A network 10, such as the Internet, but not necessarily restrictedthereto, is bidirectionally accessible by any one of a plurality ofclient devices 12. Each of the client devices 12 can be, but is notlimited to, a network enabled smart phone, tablet, or other computingdevice such as a laptop, palmtop, or desktop personal computer. As newtypes of computing devices are developed, these too can be employed asclient devices 12.

Service provider clients 14 are also bidirectionally coupled to thenetwork 12. The service provider clients 14, in this instance, provideservices of interest to the users of the client devices 12 and cancomprise, but are not limited to, insurance services, record keepingservices, banking services, retail services and any other type ofservice that maintains records that may be of interest to the users ofthe client devices 12.

The client devices 12 are operable to connect with a secure data storageserver 16. The service provider clients are also operable to connectwith the secure data storage server 16.

As will be described hereafter, the secure data storage server 16interacts with the client devices 12 and the service provider clients 14to provide a data storage service that is both secure in what is storedand secure in its sending and receiving.

While FIG. 1 shows a plurality of client devices 12 and service providerclients 14, the invention is hereafter explained as, for each task,employing just a single client device 12 interacting with the securedata storage server 16 together with a client device 12 user selectedservice provider clients 14.

In examples explained hereafter, each client device 12 may be operatedin the presence of a point of sale terminal 13 with which it can be innear field communication 15. In the examples given hereafter, the clientdevice is, for preference, a portable devices such as a smart phone ortablet. The portable device 12 can provide information concerning theidentity of the user to the point of sale terminal 13 either by nearfield communication 15 or by display of a two dimensional barcode to thepoint of sale terminal 13.

The secure data storage server 16 comprises an Crypt app server 17 thatinteracts with the client device 12 when required, and with the point ofsale terminal 13 when required, to receive and send data and requestsand commands from and to the point of sale terminal 13 (when it isinvolved and the client device 12). The Crypt app server 17 uses thecontents and services of one or more personal data store(s) (PDS),described hereafter, to provide secure data storage and useful servicesderived therefrom. A context data is stored 19 is associated with thecrypt app server 17 and stores data derived and found from the use ofthe app.

The crypt app server 17 also provides service for a plurality of apps(computer programmes accessed by a client device 12 using a graphicalinterface). The crypt app server 17 provides data decryption services toread the stored encrypted information from the service provider clients14 and the stored encrypted information provided by the client device12.

While the secure data storage server 16 is shown in FIG. 1 and anintegral whole, it is to be appreciated that the present invention alsoprovides that the secure data storage server 16 can be implemented as aso-call “cloud” arrangement where a plurality of singly addressableinter-operative network sites co-operate with one another to provide thefunctions described.

Attention is next drawn to FIG. 2, a schematic diagram illustrating ingreater detail the arrangement of FIG. 1 when executing a task. Wherecommunications are shown, it is to be understood that thosecommunications are provided through the network 10. FIG. 2 contains manyelements in common with those shown in FIG. 1, and it is to beunderstood that like reference numerals denote like items.

The secure data storage server 16 comprises, as well as the Crypt appserver 17, a change server 18. The change server 18 communicates withthe selected service provider client 14 by means of a service providerto change server connection 22 and the client device 12 communicateswith the change server 18 by a client device to change server connection20.

The secure data store server 16 also comprises one or more securepersonal data store(s) (PDS) 24 where in data is stored in ahyper-secure manner. The service provider client 14 is coupled to thepersonal data store 24 by a service provider to personal data storeconnection 26 allowing encrypted data to be stored and recovered. Theclient device 12 is coupled to the personal data store 24 by means of aclient device to personal data store connection 28, allowing encrypteddata to be stored and recovered.

The secure data storage server 16 also comprises a crypt manager 30operable to manage the information stored in the personal data store 24.

The service provider to personal data store connection 26 for preferenceemploys a public key to access the personal data store 24, with therestriction that communication can only be effected via known IPaddresses.

The client device to personal data store connection 28 for preferenceemploys a private key to access the personal data store 24.

According to a first option for stored company data encryption, companydata is stored within the personal data store 24 using the same publickey access as is used in the service provider the personal data storeconnection 26, thereby providing a technical advantage of avoidingdecryption and re-encryption for storage.

According to a second option for stored company data encryption, companydata is stored within the personal data store 24 using a company privateencryption key.

According to a first option for stored personal data encryption,personal data is encrypted using the same customer communication key asis used in the client device to personal data store connection 28. Thismeasure provides a technical improvement by avoiding the necessity ofdecryption and re-encryption of the personal data.

According to a second option for stored personal data encryption,personal data is encrypted using a customer private encryption key.

The change server 18 provides two separate channels, a first channelbeing for informing the client device 12 of changes made by the serviceprovider client 14 and a second channel being for the client device 12informing the service provider clients 14 of changes made by the clientdevice 12.

A supplier of data for storage in the personal data store 24 only hasrights to access or change specific data.

Although only one personal data store 24 is shown in FIG. 2, it is to beappreciated that the invention allows for the provision of multipleindividual person data stores and data store elements, sufficient toaccommodate the very large amounts of data to be stored and retrieved.Similarly a personal data store may be a subset or partition of anotherdata store, with the appropriate access controls as described previouslyproducing the same effect

Encryption of stored data within the personal data store 24 with anunknown key (for example the customer's well known word) means that noone else, not even the owners of the personal data store 25 and itsperipheral parts, can read data stored therein. The data remains securefor all time. If a user forgets his ability to access, and has to startagain, the customer is assured that his “lost” data cannot be accessedby others.

The personal data store 24 is described hereafter as being employed by auser to create associations or link between suppliers and products andto establish product status. It is to be understood that the personaldata store 24 is also employed to store identity of supplied productsand status, as well as identification for the individual user.

Attention is drawn to FIG. 3 illustrating exemplary data flow that canbe undertaken using the apparatus of FIG. 2. In this example, a pensioncompany updates an individual customer's record with a new pensionamount. It is to be understood that the invention is not limited to thisexample, and the company can be for any purpose and amend any record ofany kind.

From a start 32 a first test 34 checks to see if the insurance companyis ready to update a customer entry. If there is no updating to be done,operation stays in the first test 34. If the insurance company is readyto provide a customer update, a first operation 36 communicates to theservice provider 14 client software an indication of the type of policy,the policy identifier and the new amount in the pension fund. Theservice provider 14 also comprises an adapter. A second operation 38working through the encryption adapter software finds the customer andobject identifier and a third operation 40 also provides data to be sentto the personal data store 24 such as indication of the nature of thedata to be upgraded, the document identifier, the identity of the finaluser and the fund amount. It is to be understood that in othercircumstances different types of data would be selected for storage inthe personal data store 24. A fourth operation 42 then has theinformation encrypted to be sent from the service provider client 14 tothe personal data store 24 using the public key and IP addressidentification as described above. A fifth operation 44 then sends theinformation to the personal data store (PDS) 24.

The service provider client 14, in a sixth operation 46, then contactsthe change server 18, shown in FIG. 2, to indicate to the customer thata change has been made to the content of the personal data store 24 fordata from the service provider 14 for the particular customer (as can becontacted through the client device 12). The message might be, forexample, “fund amounts changed made to document ID 170”. Whatever themessage actually is, the message reflects the nature of the change in anon-informative way to avoid giving out information to anyeavesdroppers.

Thereafter, the customer can activate the client device 12 to access thepersonal data store 24 to learn new information. The message provided tothe customer by the sixth operation 46 is, for preference, encryptedboth from the service provider client 14 and when delivered to theclient device 12.

The personal data store 24 has the crypt manager 30 manage the personaland public data of the customer, and private and public data of thecompany.

In a second example, the situation is shown where a customer may haveseveral products from the same company. Unfortunately, in this instancethe company or company systems are arranged on a “product-silo” basis,and it is often difficult to create a quote single customer view” of allof the products a customer has. In the past, the customer was requiredto employ complex and error-prone matching of customer data across manycompany systems.

The present invention allows creation of a “single customer view” bymatching data in the personal data store and company systems andassociated challenge response with the customer.

Attention is next drawn to FIG. 4, a schematic diagram showing how thepersonal data store 24 stores two types of data.

The personal data store 24 provides a store for each of two types ofdata.

A first type of data is private data and is stored in a person's privatecompany data memory 48. The private data memory 48 stores such things ascompany data that is not available for public knowledge.

A second type of data is persons public data stored in a user publicdata memory 50. The public data memory 50 stores such things as namesand addresses and other publicly available information that helps toidentify a particular customer. Further data can be, but is not limitedto, first name, surname, and date birth.

Each item of private data held in the user private data memory 48 mayhave a corresponding item of persons public data held in the public datamemory 50, as indicated by association arrow 52.

While there is only one personal data store 24 shown in FIG. 4, It is tobe appreciated that the invention provides for more that one personaldata store 24 to be provided. The invention also provides that eachpersonal data store 24 can accommodate only one, or more than one ofeach type private 48 and public 50 data memories. The invention merelyrequires that the different data can be stored and retrieved asdescribed.

The arrangement of the personal data store 24, is such that a companymay define data to be private to the company, or made public andavailable to a specific customer.

Similarly the arrangement of the personal data store 24, is such that acustomer may define data to be private to the customer, or made publicand available to a specific company.

The status of customer data being made public or private can be changedat the discretion of the customer, either for a limited time/specificinteraction, or ongoing

Similarly the status of company data being made public or private can bechanged at the discretion of the company, either for a limitedtime/specific interaction, or ongoing.

Attention is next drawn to FIG. 5, a flow chart illustrating one way inwhich the secure data storage server can create a “single customer view”from diverse data, referred to above as the second problem.

The solution to this the second problem is dependent upon the priorsolution of the fifth problem as described hereafter with reference toFIG. 7.

From a start 54 a second test 56 looks to see if a single customer viewis desired. If the second test 56 finds that a single customer view isdesired, a seventh operation 58 selects the individual customer for whoma single customer view is to be created. The selection is achieved byselecting from the user public data memory 48.

An eighth operation 60 then selects a product owned by the individualthrough the company which it has been decided to create a singlecustomer view. This can be selected by the customer, or the singlecustomer view selection started during a customer inspection sessionwhere both customers public and private details are available for asingle product.

What ever way the company and individual are selected, at the end of theeighth operation 60 all the information necessary to create a singlecustomer view is available. A ninth operation 62 then scans the contentsof the personal data store 24, looking for matches between the selectedindividual customer, details of which are found in the persons publicdata memory 48, and the selected company and products found in thepersons five data memory 50.

A third test 64 checks to see if all of the records possible to the endof the personal data store 24 have been checked.

If the third test 64 finds that there are still records remaining to besearched in the personal data store 24, a fourth test 66 checks to seeif a match between the selected individual and the selected company hasbeen found. If the fourth test 66 finds that no match has been found,control is passed back to the ninth operation 62 to continue checkingfor matches.

If the fourth test 66 finds that a match has been found between theselected individual and a selected company, a tenth operation 68 addscustomer and company product details to an agglomerated single customerview. Control is then passed back to the ninth operation 62 to continuechecking the personal data stores 24 for matches.

If the third test 64 finds that the personal data store 24 has beentotally checked and no further matches will be found, and eleventhoperation 70 stores the aggregated single customer view, as collected inthe tenth operation 68, in, for preference, a customer personal programarea such as an App allowing a customer to call up their single customerview at any time.

For preference, the single customer view is used or maintained on eachoccasion that the customer updates are personal information (e.g.telephone number) and the personal program area (App) informs thecompany product systems of the changes.

A third problem arises when a customer requires to communicate with theright person in the company. Finding the right person to talk to can bevery error prone and a customer is required constantly to provide thesame security of personal data at each step along the chain until theright person is reached.

The present invention allows an individual to avoid such difficulties.

To obtain access to the right support from a company, typically at leastthree sets of data are required. A first set of data identifies theproduct that the customer needs support with. A second set of data isthe details within that company specific to the product. A third set ofdata comprises authentication information to allow a support person toknow they are dealing with the product owner. In addition, otherinformation may be required such as whether or not the customer has beenallocated a specific relation manager and details of any can previouscommunications that have been made around the product and around thesupport need.

The secure data storage server 16, as earlier described, comprises auser public data memory 46 and a user private data memory 50. Thecompany links a product with a customer, thereby creating an objectwhich is stored in the user private data memory 50 data to representthat product, the record containing all key information around thatproduct.

If available, the company also adds extra information regarding supportwhich is not typically displayed to the customer. Such information caninclude: which phone number or video call address is correct specific tothe product, and the customer is in a specific segment, for example,“high net worth” or “must retain”. Please contact details may bepersonalised to phone numbers and/or addresses that have reduce queuesor higher trained staff, to give but two examples. The extra informationcan also give details of whether the customer has a specificrelationship manager, broker etc, and provide details of this, andassociated contact information.

The customer, using the smart phone client device 12, places a callthrough the crypt app server 17, with the customer providing informationas for which product they require support.

The crypt app server 17 then employs the personal data store 24 tocontain information relative to the company and product and to route thecontact, which can be a voice call, a video call, a conference call orsimilar communication, to the correct part of the company, appropriaterelationship manager, and so on. In addition, the public key for thecustomer can be passed the company which allows the company to retrieveidentity and/or indication information from the personal data store 24through integration with interactive voice systems, meaning thatinformation does not require to be provided by the customer.

Furthermore, when an agent of the company is connected with the call,the customer public key and personal data store 24 access allowsinformation around the product the customer requires support for in anyprevious correspondence to be provided to the agent of the companyautomatically.

Attention is drawn to FIG. 6A, an exemplary flowchart illustrating oneof many ways in which the invention can be employed to overcome thethird problem. FIG. 6A shows how a Link is created between a product anda user.

From a start 74 a fifth test 76 looks to see if an association or “link”is to be created between an individual user and a product. Such anassociation can be set up when the user first purchases a product, orcan be set up later when a product requires assistance. In any event,the action shown in FIG. 6A takes place when the service provider 14 isonline and has access to the personal data of a user.

If no association is to be made, control is passed to the fifth test 76.If an association or link is to be made, control is passed to a twelfthoperation 78 that creates a product support object stored within theprivate data memory 50. As earlier stated, the support object includesinformation identifying the product that the customer needs supportwith, any data from the supplying company specific to the product, andauthentication information to allow a support person to be aware whetheror not they are dealing with the product owner. Other information canalso be supplied, as stated, whether or not the customer has beenallocated a specific relation manager, and details of any previouscommunication made around the product and around support need.

Other information includes direction of any calls from the productcustomer to the product supplying company.

Attention is next drawn to FIG. 6B, an exemplary flow chart illustratingone way in which the crypt app server 17 can interact with a user makinga call seeking product assistance from a company.

From a start 80 a sixth test 82 looks to see whether the crypt appserver 17 call has received from a mobile telephone client device 12seeking product assistance from a company. If the sixth test 82 findsthat such a call has been received, a thirteenth operation 84 seeks toobtain the product identity from the user is seeking product assistance.If a seventh test 86 finds that no information that can be identifiedhas been obtained, control is passed back to the sixth test 82 therebyeffectively terminating the process. If the seventh test 86 finds thatthe product has been adequately identified, a fourteenth operation 88gets the personal information and the product support object from thepersonal data stored 24 and a fifteenth operation 90 gets the retrieveddata of the fourteenth operation 88 ready to show to the company callrecipient when a call is made. A sixteenth operation 92 then places thecall to the company and to the designated individual from the productsupport object until an eighth test 92 detects that the caller has hungup. Control then passes to a seventeenth operation 96 that has the cryptapp server terminate the call and passes control back to the six test 82ready to receive any other incoming call seeking product assistance formy company.

At the end of this process the company can add new information to theproduct support object giving details obtains during the course of thecall that has been made.

A fourth problem arises when a customer comes to purchase financial orother service-based products online. In such circumstances, the customeroften has to provide a significant amount of personal details, identitydetails, historic and perhaps payment details. Such information must berepeated for each new supplier although the data required often variesonly slightly, if at all, across the supplier. The present inventionprovides minimisation of data required to process product applicationsthe use of the personal data store 24, including (if required)authentication of the user.

The customer, using the client device 12 via the crypt app server 17,requests setting up a product (i.e. he/she would like to take up anoffer to purchase the product or service). In registering the product,the customer initially provides only indication of the type of product(e.g. car insurance) and indication for the product (for example, policyidentification).

At this point, the secure data storage server 16 informs the selectedthe supplier that they would like to link that supplier product to theirwebsite and/or application. To prevent the possibility of fraud, thesupplier requires additional information to ensure that the customer iswho they say they are. Such information can include postcode, dates ofbirth, bank used for direct debits, and so on. This is a validationtemplate, that is, template of the type of information that must bevalid in order to pass security for the supplier, and typically, someitems of information may be more important than others. For example, thedate of birth may be more important the mobile phone numbers which canperform out of date.

The secure data storage server 16 uses the personal data stored in theuser public data memory 48 and elsewhere in the personal data store tomatch the validation template. Only when the validation data is notavailable in the personal data store 24 and/or does not match that heldby the supplier, is the customer prompted to supply the correct datanear the Or website. The vast majority of data will not need to beentered by the customer, and only when there is absence of data or amismatch.

If all the validation is passed, then the account becomes linked to thecustomer in the personal data store 24, and appropriate productinformation is pushed to the customer via the personal data store 24 andthe secure status storage service 16 and/or its app 17. Such informationcan include, in the case of insurance, policy details, policy documents,further office and so on.

A fifth problem can be resolved where use of the personal data store 24assists in customer transactions when a particular customer desires toaggregate all of their existing products or policies with one or moresuppliers into a single application or website. To do this in the mannerpreviously available, entails supplying existing logon and/or identityinformation for each product, being manually entered by the customer.Such a process is not only very insecure but is also time consuming andrequires the customer to have set up full access for each product onprevious occasions.

The customer using the client device 12 has an account with the personaldata store 24. This account, as earlier stated, is hyper-secure with alldata highly encrypted in the personal data store 24 and encrypted duringtransmission (e.g. using HTTPS). The personal data store access also hasa scheme for identifying a user, for example but not limited to,provision of a user name and/or password. There is also a “private key”scheme for decrypting data whereby, as an example, the customer providesmemorable words. The memorable words is then used as theencryption/decryption key for data from the customer.

Further security schemes may also be provided including registration ofphysical devices such as tablets and phones running an applicationinterface (App). Once a user has authenticated themselves, they can pushor pull information into and out of the personal data store 24 via anappropriate interface program (app) or website accessing the applicationprogram interface (API) for the personal data store 24, using thecustomer private key.

As was earlier stated, the personal data stores 24 personal information,such as date of birth, name, addresses, asset such as cars etc, in apersons public data memory 48 (shown in FIG. 4) and stores privateinformation (such as bank accounts, insurance policies, mobile accountsand so on) in a user private data memory 50, also shown in FIG. 4. Otherinformation can also be held such as communications from suppliers,policy documents, applications for product etc.

For each product or policy that a customer has, then any form ofphysical documents such as policy documents, statements and so on, canbe printed with a two dimensional barcode (QR code), barcodes or similaridentifying image. Where a customer does not have any physicaldocuments, then the supplier can email them their identifying image, orcan otherwise text or distribute to the customer. The identifying code,such as a QR code, identifies the company, type of product and theproduct identifier, such as a policy number. For additional security,these identities may not be those publicly used, but maybe, instead bein internal identifying used by the company.

The customer then uses the crypt app server 17 to send the identifyingcode. The sending of identifying code causes the product automaticallyto be linked. This is in contrast with the situation where the customeris communicating without the use of a QR code or similar, in which casethe customer would have to manually enter the identifying productinformation.

Using the customer's public key, the company is able to securely accessthe customer's personal data store 24 and to review both the internalidentifying information scanned from the image code (QR), andinformation useful to authenticate that a policy of product does indeedbelong to the customer, such information including address, date ofbirth, and any other relevant personal identifiable data.

The company then runs an appropriate risk-based data matching routinethat determines if the customer information retrieved from the personaldata store 24 matches that retrieved from the product or policyidentified if the information does not match, but the mismatch is veryclose, the company asks the customer one or more questions, using thecrypt app server 17 for correct data to match the selected policy orproduct.

In those circumstances where the match is not perfect, or the additionalsecurity questions do not create a match, the company asks the customerone or more security questions using the crypt app server 17 that arenot typically stored in the customer's personal data store 24.

Assuming there is sufficient match to positively identify the customeris the owner of the product or policy, then an appropriate“product/policy object” is created in the personal data stored 24,together with associated documentation. This then enables the customerto interact and manage with the product policy object using the cryptapp server 17 without further authentication being required.

Attention is drawn to FIG. 7 showing an exemplary flow chartillustrating one possible way in which the present invention assists toresolve the fifth problem.

The left-hand column of FIG. 7 shows the activities that take placewithin the crypt app server 17 in its transactions with a user 12. Theright-hand column of FIG. 7 shows operations undertaken within thesecure data storage server 16.

From a start and 98, in an eighteenth operation 100 the customer 12contacts the crypt app server 17 and indicates in a nineteenth operation102 what supplier is required and the type of product that is requiredfrom the supplier. A twentieth operation 104 then requests to the cryptapp server 17 that a link be formed and passes the request to a twentyfirst operation 106 in the secure data storage server 16.

In a twenty second operation 108 the supplier accesses the personaldata, as described above, of the customer and applies the validationtest to see if the customer is genuine. A ninth test 110 checks to seeif data is needed from the customer, the customer Supply data also beingas described above. If no data is required from the Customer, a tenthtest 112 looks to see if the customers request has passed the validationtest. If the customer's approach has not passed the validation test, theprocess ends via exit 116. If the customer's approach has passed thevalidation test, the interaction between the supplier and the customercarries on through continuation 118.

If the ninth test 110 finds that more details are needed from thecustomer to be applied to the validation test, the ninth test passes therequest to a twenty third operation 114 of the crypt app server 17 whichgathers stay requested information, as described above, and includes itin the criteria for the tenth test 112 to determine whether or not thevalidity test has been passed.

A sixth problem in which the present invention, by use of the personaldata store 24, can assist occurs when a customer, at a retail outlet,desires to purchase a product. This often leads the customer to providesignificant amounts of personal information, such provision being madeby word-of-mouth and data entry being made by a person in attendance,typically at a point of sale terminal 13. Such a time-consuming processthat is often repeated, as will be seen, is unnecessary when the presentinvention is employed.

Returning attention briefly back to FIG. 1, in such a sales situationthe client device 12 is close by the point of sale terminal 13. As afirst option, the client device 12 can provide near field communication15 with the point of sale terminal 13. As another option, the point ofsale terminal 13 can capture an image displayed on the screen of theclient device 13. The image represents the identity of the client device12 and points to personal data and company data related thereto.

The point of sale terminal 13 is put into communication with the cryptapp server 17, indicated in FIG. 1 by broken line. The point of saleterminal 13 relays the near field communication 15 from the clientdevice 12, and/or transmits the captured image to the crypt app server17.

As earlier stated, the personal data store 24 stores the customerspersonal identification data in the user public data memory 48 (shown inFIG. 4) and stores the customers company memory in the user private datamemory 50.

The crypt app server 17 employs the facilities of the secure datastorage server 16. The customer may desire to share their personalinformation (name address etc) and product information (bank accountetc) with a retailer in order to simplify and speed up the purchaseprocess, and to create a new policy or contract. Other information couldalso be useful for the retailer. Such information can includeauthentication tokens as proof of identity, credit history and creditrating, copies of existing contracts such as utility bills, and so on.

The crypt app server 17 uses the customer public key to push a messageto the customer telling the customer what information the retailerwishes to obtain in order to set up a contract. The customer then hasthe option to except this data requests, or to reject it.

If the customer chooses to accept the request to access thisinformation, this is provided to the retailer. If all of the informationis available in the customers personal data store 24, then the retailercan create a contract or policy immediately, and can push the policy orcontract into the crypt app server 17. The customer may then see thepurchased product information.

If the customers personal data store 24 does not contain all informationrequired by the retailer, then further questions/obtain this data aredisplayed to the point of sale operator in the store prompting them toas the customer to provide the missing information. This is deemed to bemore efficient than prompting the customer using messages from the cryptapp server 17, but may be done via the client device for someidentifying information (e.g. provide fingerprint, or password) thatshould not be shared with the point of sale operator.

Once a missing data is provided by the customer, this information isalso stored in the customers personal data store 24, assuming thecustomer's happy so to do, so that the need for the customer to be askedthe same question again disappears.

Yet another problem that can be solved by use of the personal data store24 lies in, for example, loyalty programs.

Attention is once again redrawn to FIG. 1.

The personal data store 24 for a customer is hyper-secure with all ofthe data encrypted in the personal data store and encrypted duringtransmission to and from the personal data stored. The personal datastore 24 also includes a scheme for identifying a customer, for example,a username combined with a password, and a private key scheme fordecrypting data, such as employing a memorable word to act as anencryption key for that data. Further security schemes may also be putinto place including registration of physical devices such as tablets,where phones and other apparatus. Once a customer has authenticatedthemselves they may pull or push information into the personal datastore 24 with an appropriate app, website and application programminginterface (API), using the customer private key.

The customer can use this facility to associate one or more loyaltyaccounts with the personal data store 24 via the crypt app server 17employing the secure data storage server 16.

The crypt app server 17 can then employ the app as part of one or moreloyalty programs. This can include: registering that an appropriatepurchase was made that is eligible within a particular loyalty program;registering that an appropriate access to services was made that iseligible within a particular loyalty program; pushing loyalty programoffers to the crypt app server using the associated app including whenand perhaps where purchase was made; and using redemption points from aloyalty program for associated discounts at a point of sale 13.

To summarise the invention as described:

1. Each customer has a personal data store where data storage and accessis secured by public/private key encryption, and encryptedcommunications using, for example, HTTPS encryption.2. Each company has a personal data store for each customer, where dataand access is secured by public/private key encryption, andcommunication by using encryption.3. The service maintains a context data store of relationships betweencustomers and companies and service/products provided where data storeand access is secured by public/private key encryption andcommunications using encryption4. Furthermore there are IP address restrictions and/or the use ofVirtual Private |Network) (VPN) tunnels for accessing customer, companyand context data stores (e.g. company can only access customers datastore where request originates from a specific known IP range/VPN)5. Further Security is provided by: the personal data store 24 beingunique to an individual—access to one store does not provide access toany other store (and hence other customers data)6. Further Security is also provided by the Personally identifiablecustomer data only being stored in the customer personal data store; andthe requirement that the customer must give explicit read/write/createaccess to companies to access the customer personal data store; andcompanies must access through known IP address ranges.7. Yet further security is provided by the product information for acustomer being stored in a company personal data store specific to thatcustomer, which the company may give explicit read access to some itemsof data to the customer. This personal data store does not have customerpersonally identifiable data—hence if compromised could not establishwhich customer the data is for8. Still more security is provided by the context data store, thatdescribes the relationship between customers, companies andproducts/services, for example that a particular customer has anidentified product from a specified company, holds only internalrepresentations of customer, company and product, hence if datacompromised it could not be possible to establish customer, company orproduct

In addition, the personal data stores can be virtual—e.g. a companypersonal data store may be a protected area within a customers personaldata store. However personal data stores are always individual tospecific customers, and access to one PDS 24 does not provideinformation for other customers

The invention has so far been described with reference to specificexamples. It is to be appreciated that those skilled in the art will beaware of many variants and modifications that can be applied in theexamples given above without deviating from the invention as claimed.

The invention is further explained and clarified by the claims appendedhereafter.

1.-40. (canceled)
 41. A system for controlling bidirectionalcommunication comprising: a server communicatively connected to at leastone data store comprising application data having public data andprivate data; a security mechanism coupled to the server; and anapplication capable of bidirectionally communicating with the server viathe security mechanism, the security mechanism further comprising, anapplication programming interface that can be used by the application tointeract with the server; a security condition, wherein the securitymechanism determines if the security condition is met, the determinationincluding at least using first application data from the application,wherein the first application data is encrypted and stored using a firstprivate key, and using second service provider data from the server,wherein the second service provider data is encrypted and stored using asecond private key.
 42. The system according to claim 41, wherein thedetermination that a security condition is met includes receiving andsending application data, service provider data, requests and commands.43. The system according to claim 41, wherein the server accesses the atleast one data store only from a previously registered IP address, or atoken.
 44. The system of claim 41, wherein the security mechanism isconfigured to make a determination whether the application supplied apassword or a token, as a condition for the security condition beingmet.
 45. The system of claim 41, wherein the security mechanism iscapable of encrypting one or more of the first and second private keys.46. The system of claim 45, wherein the security mechanism stores theencrypted first or the second private keys in the data store.
 47. Thesystem of claim 46, wherein the password or the token is used by thesecurity mechanism to determine whether to decrypt the first or thesecond private keys from the data store.
 48. A device, comprising: aserver communicatively connected to at least one data store comprisingapplication data having public data and private data; a security devicecoupled to the server; and an application capable of bidirectionallycommunicating with the server via the security mechanism, the securitymechanism further comprising, an application programming interface thatcan be used by the application to interact with the server when asecurity condition is determined to be met by the security device, thedetermination including at least using first application data from theapplication, wherein the first application data is encrypted and storedusing a first private key, and using second service provider data fromthe server, wherein the second service provider data is encrypted andstored using a second private key.
 49. The device according to claim 48,wherein the determination that a security condition is met includesreceiving and sending application data, service provider data, requestsand commands.
 50. The device according to claim 48, wherein the serveraccesses the at least one data store only from a previously registeredIP address or a token.
 51. The device of claim 48, wherein the securitymechanism is configured to make a determination whether the applicationsupplied a password or a token, as a condition for the securitycondition being met.
 52. The device of claim 51, wherein the securitydevice is capable of encrypting one or more of the first and secondprivate keys.
 53. The device of claim 52, wherein the security devicestores the encrypted first or the second private keys in the data store.54. The device of claim 53, wherein the password or the token is used bythe security device to determine whether to decrypt the first or thesecond private keys from the data store.
 55. A method for controllingbidirectional communication, the method comprising the steps of:providing at least one server communicatively connected to at least onedata store comprising first data having public data and private datarelating to an application, wherein the server is bidirectionallycommunicating with the application and a third-party device; obtainingthe first data from the at application, wherein the first data isencrypted and stored using a first private key; obtaining second datafrom the at least one third-party device, wherein the second data isencrypted and stored using a second private key; receiving a request viaan application programming interface from the application to interactwith the third party device; and using a security mechanism capable ofdetermining if the application can interact with the third-party device.56. The method of claim 55, wherein the step of using a securitymechanism further comprises: receiving a password or a token that isused to determine if a security condition has been met.
 57. The methodof claim 55, wherein the step of receiving a request further comprises:providing a user interface to the application and receiving the requestvia the user interface.
 58. The method of claim 57, wherein the step ofusing further comprises encrypting one or more of the first and secondprivate keys.
 59. The method of claim 58, wherein the step of usingfurther comprises storing the encrypted first or the second private keysin the data store.
 60. The method of claim 59, wherein the step of usingfurther comprises using the password or the token to determine whetherto decrypt the first or the second private keys from the data store.